home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Almathera Ten Pack 3: CDPD 3
/
Almathera Ten on Ten - Disc 3: CDPD3.iso
/
scope
/
001-025
/
scopedisk5
/
fastdisk
/
german.doc
< prev
next >
Wrap
Text File
|
1995-03-18
|
9KB
|
234 lines
FastDisk V1.5
Für AMIGA 500/1000/2000
Sprache : Aztec C - V3.4a
Written 1987 by:
Torsten Stolpmann
Wilhelm-Raabe Str. 26
6750 Kaiserslautern
Was ist FastDisk?
FastDisk ist ein Programm zur Optimierung der zum Teil chaotischen
Diskstruktur von Amiga-Disketten.
Jeder kennt die, manchmal bis zu mehreren Minuten dauernde, Wartezeit auf
das Einlesen eines längeren Directorys.
FastDisk beschleunigt diesen Vorgang in der Regel um das drei- bis
fünffache.
Jeder kennt das verzweifelte Kreischen der Laufwerke beim Einlesen von
Workbench-Icons.
FastDisk reduziert die Kopfbewegungen des Laufwerks auf ein Minimum.
FastDisk beschleunigt die Validierungszeiten (nach Einlegen einer neuen
Diskette) und den Bootvorgang.
FastDisk ist in der Lage, die Ladezeiten von Diskette um typischerweise
30-50% zu verringern.
Was macht FastDisk?
FastDisk erreicht die obigen Ergebnisse, indem es eine Diskette sektorweise
kopiert, allerdings werden die physikalischen Positionen der Sektoren auf
der Zieldiskette verändert. Das ist alles. Die Zieldiskette ist weiterhin
eine normale AmigaDos-Diskette, es entstehen keine Kompatibilitätsprobleme.
Wie funktioniert FastDisk?
Um die Funktionsweise von FastDisk zu verstehen, muß man sich mit der Art
beschäftigen, in der AmigaDos die Diskette verwaltet. Nähere (wenn auch
nicht immer ausreichende) Informationen hierzu findet man im
AmigaDos-Manual.
Hier nur die wichtigsten Informationen:
Die 1760 Sektoren (Blocks) zu je 512 Byte einer AmigaDos-Diskette werden in
folgende Typen unterteilt:
1. Bootsectoren
2. Rootblock
3. Directory-Blocks
4. Fileheader-Blocks
5. Filextension-Blocks
6. Datenblocks
Die Bootsectoren sind immer die Sectoren 0 und 1. Diese sind auf jeder
AmigaDos-Diskette vorhanden und werden beim Booten der Diskette gelesen und
(falls es sich um eine bootbare Diskette handelt) wird ein sich dort
befindliches Programm ausgeführt.
FastDisk kopiert diese Blöcke unverändert.
Der Rootblock (er befindet sich immer im Sector 880) enthält neben diverser
weiterer Informationen (z.B. Diskettenname, Creationdate etc.) eine 72
Einträge große Hash-Tabelle mit Zeigern auf alle Files/Directories, die
sich in der Root-Directory befinden.
Diese Einträge in der Tabelle sind nach einem festgelegten Hash-Algorithmus
geordnet, hierzu wird der File/Directory Name herangezogen.
Falls es sich bei einem Eintrag um einen Directoryeintrag handelt, so zeigt
der Zeiger auf einen Directoryblock, der ähnlich dem Rootblock aufgebaut
ist.
Falls es sich um einen Fileeintrag handelt, so zeigt der Zeiger auf einen
Fileheaderblock. Es müssen nicht alle Einträge in der Tabelle belegt sein,
daher werden Zeiger vom Wert NULL als nicht belegte Einträge interpretiert.
Nun kann es vorkommen, daß mehrere Einträge den gleichen Platz in der
Hash-Tabelle haben können (Der Hash-Algorithmus liefert die gleiche
Position in der Tabelle).
Diese Kollisionen werden derart aufgelöst, daß die betreffenden
Headerblocks über einen entsprechenden Zeiger im Headerblock zu einer
linearen Liste verkettet werden.
Die Fileheaderblocks enthalten nun wiederum eine 72 Einträge große Tabelle
mit Zeigern auf alle Datenblocks, die zu dem betreffenden File gehören.
Da die Tabelle nur 72 Einträge beinhaltet wird für den Fall, daß ein File
mehr als 72 Datenblocks beansprucht, eine einfach verkettete Liste von
Fileextensionblocks angelegt, diese Blocks können jeweils weitere 72
Einträge fassen.
Außerdem ist es wichtig zu wissen, daß Disketten-I/O beim AMIGA
trackorientiert ist, das heißt, daß sobald eine Spur auf der Diskette
angefahren wird, die gesamten Sektoren dieser Spur eingelesen werden, und
solange im Speicher zur Verfügung stehen, solange der Schreib-Lesekopf
diese Spur nicht verläßt. Dies kann von grossem Vorteil sein, wenn die
physikalische Positionierung der Blocks auf der Diskette entsprechend
vorgenommen wurde.
Zur Optimierung der Diskettenstruktur bieten sich grundsätzlich folgende
Möglichkeiten:
1. Die physikalische Reihenfolge der File/Directoryheader auf der Diskette
wird entsprechend der Reihenfolge in den Hashtabellen angelegt. Da die
Kommandos zur Auflistung der Directories entlang der Hashtabelle vorgehen,
werden diese enorm beschleunigt. Auch die Validierungszeit wird hierdurch
verkürzt.
2. Zur Plazierung der Fileheaderblocks bieten sich grundsätzlich zwei
Möglichkeiten an, entweder man gruppiert alle Headerblocks möglichst nahe
an den Roottrack (was das Einlesen des Directorys beschleunigt), oder man
legt die gesamten Datenbloecke jeweils direkt hinter ihren Headerbloecken ab (die Headerblocks sind jetzt zwar ueber die gesamte Diskette verstreut,
allerdings wird hierdurch das Laden von Files beschleunigt, da für den
Headerblock nicht mehr ein weiterer Track auf der Diskette angefahren
werden muß).
Für die Directoryheader bieten sich ähnliche Lösungen an, im Falle
schneller Directories empfiehlt sich eine Gruppierung innerhalb der
Fileheaderblocks (die entsprechende Position ergibt sich aus der
Hash-Tabellen-Position.
Für möglichst schnelle Ladezeiten hat es sich als vorteilhaft erwiesen, die
Directoryheader im Roottrack unterzubringen (also direkt hinter dem
Rootblock), normalerweise reicht dieser Platz aus, um alle Directoryheader
unterzubringen.
Wie man sieht haben beide Moeglichkeiten ihre Vor- und Nachteile, darum
wurde beide Optimierungsverfahren implementiert, je nachdem ob man bei der
jeweiligen Diskette mehr Wert auf ein schnelles Directory (z.B.
Datendisketten) oder auf einen schnellen Ladevorgang legt (z.B.
orkbench-Disk).
AmigaDOS selber verfolgt übrigends bei der Positionierung der
Diskettenblocks eine Strategie, die die Nachteile der beiden obigen
Verfahren kombiniert. Es wird versucht den Headerblock und den ersten
atenblock des Files hintereinander in der Nähe des Roottracks abzulegen
(der Rest wird irgendwo außen abgelegt). Dies sollte das Laden von sehr
kurzen Files, die nur einen Datenblock beanspruchen, beschleunigen (z.B.
system-configuration, .info-Files etc.).
FastDisk geht hier konsequenter vor, und legt grundsätzlich alle folgenden
Files hinter ihrem Headerblock ab:
Startup-Sequence
System-Configuration
alle Files mit der Endung .info
Wann funktioniert FastDisk nicht?
FastDisk benötigt mindestens zwei Diskettenlaufwerke.
FastDisk benötigt Chip-Memory. Viel Chip-Memory.
Beim Kopiervorgang werden alle Header- und Directoryblocks im Speicher
gehalten. Sollte hierfür nicht genügend Chip-Memory zur Verfügung stehen,
bricht das Programm ab.
Auch ansonsten sollte man FastDisk soviel Speicher wie möglich zur
Verfügung stellen, da FastDisk während des Kopiervorgangs versucht, erst
später benötigte Sectoren, die sich bereits im Trackbuffer befinden, im
Speicher zur Verfügung zu halten (Cache). D.h. je mehr Speicher zur
Verfügung steht, desto schneller läuft der Kopiervorgang ab.
FastDisk erwartet eine eine Standard-AmigaDOS-Diskette, d.h. es sollten
sich insbesondere keine Sectoren auf der Diskette befinden, die nicht von
AmigaDOS verwaltet werden, da diese (abgesehen von den Bootsectoren) nicht
mitkopiert werden.
FastDisk kann keine Disketten kopieren, deren DOS-Struktur zerstört bzw.
inkonsistent ist. FastDisk erkennt solche Fehler und empfiehlt das einzige
Hilfsmittel: DiskDoctor.
Wie bedient man FastDisk?
FastDisk kann sowohl vom CLI als auch von der Workbench aufgerufen werden.
Falls es von der Workbench aufgerufen wird, öffnet es sein eigenes Fenster
(ein Feature von Aztec 3.4a). Ein Icon mit den nötigen Einträgen im
Tooltype-Feld wird mitgeliefert.
Die Argumente für den Aufruf vom CLI lauten:
Usage : FastDisk [FROM] drive [TO] drive [FASTDIR] [NOFORMAT]
Defaults: FastDisk FROM df0: TO df1:
FROM und TO sind optional und müssen nur angegeben werden, wenn man die
Argumente unbedingt in umgekehrter Reihenfolge angeben will (Also FastDisk
df1: df0: kopiert von df1: nach df0:, FastDisk TO df1: FROM df0: von df0:
nach df1:).
Bei der Angabe von FASTDIR wird bei der Optimierung auf schnelle Directorys
geachtet, ohne Angabe wird auf kurye Ladezeiten hin optimiert.
Mit der Angabe von NOFORMAT wird die standardmäßige Formatierung der
Zieldiskette unterdrückt, dieses resultiert in etwas kürzeren Kopierzeiten,
hat aber den Nachteil, daß bei einer späteren Behandlung der Zieldiskette
mit DiskDoctor Konflikte mit früheren Daten auf der Zieldiskette entstehen
können. DiskDoctor handelt in solchen Fällen des öfteren recht
unverständlich, und entfernt auch schon mal ein eigentlich intaktes File.
Aufruf von der Workbench:
Die entsprechenden Optionen befinden sich im ToolType-Feld des
FastDisk-Icons (erreichbar über das Info-Kommando).
Die ToolTypes sind:
WINDOW= Hier steht die Definition des Windows, das beim
Start geöffnet wird, dies sollte nicht geändert
werden.
FROM= Hier steht das Quell-Laufwerk (df0: - df3:)
TO= Hier steht das Ziel-Laufwerk (df0: - df3:)
FASTDIR= ON stellt diese Option an, OFF (oder alles
andere) stellt sie ab.
NOFORMAT= Auch hier sollte ON oder OFF stehen.
Defaults: FROM=df0:
TO=df1:
FASTDIR=OFF
NOFORMAT=OFF